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REMARKS 



This paper is responsive to the Office Action dated October 6, 2006. Applicants have not 
amended any of the claims. Claims 1-43 and 50-53 remain pending. 

In the Office Action, the Examiner withdrew the previous rejection but set forth new 
grounds of rejection.' Specifically, the Examiner rejected claims 1-43 and 50-53 under 35 U.S.C. 
103(a) as being unpatentable over Armistead et al (US 6,529,959) in view of Maurya (US 
6, 160,808). Applicants respectfully traverse the rejections. The applied references fail to 
disclose or suggest the inventions defined by Applicants' claims, and provide no teaching that 
would have suggested the desirability of modification to arrive at the claimed invention. 

In general, the Examiner has mischaracterized Armistead relative to the features of 
Applicants' claims. The cited passages of Armistead do not disclose the features attributed to 
such passages by the Examiner. It appears that the Examiner has simply copied Applicants 
claims into the Office Action, and cited passages of Armistead as disclosing such features. 
However, the cited passages of. Armistead, while teaching techniques for multi-link routing, 
clearly lack the more specific features required by Applicants' claims. Furthermore, the Maurya 
reference in combination with Armistead fails to remedy the deficiencies of Armistead relative to 
Applicants' claims. Accordingly, the Examiner's rejections must be withdrawn. 

For the Examiner's convenience, Applicants once again provide a brief summary of the 
claimed inventions. This summary has already been explained on the record several times, yet 
the Examiner has persisted with rejections that are clearly deficient with respect to the features of 
Applicants' claimed invention. Nevertheless, Applicants respectfully request the Examinees 
reconsideration in view of the following comments. 

Applicants' claims generally concern a router or network device that includes one or 
more interface cards (IFCs) and a separate service card, such as a multi-link service card 
(MLSC). Various claims are directed to methods, routers and network devices. In addition, 
some of the claims, such as claim 34, are directed to the MLSC, Le. s the service card itself, which 
can be inserted into a network device to provide multi-link services for packets received and 
forwarded by other interface cards already present within the network device. 

The interface cards of the network device or router Eire used for sending and receiving 
multi-link network communications, while the separate MLSC may be used for fragmenting or 
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sequencing the communications. Alternatively, in claim 50, packet prioritization is performed i; 
the service card rather than fragmentation or sequencing. In any case, according to various 
claims, a routing component of the router or network device applies a routing function to the 
packets received from a plurality of links in one or more interface cards so as to route the packets 
to the service card within the device. At the service card, the packets are sequenced, fragmented 
or prioritized and then directed back to the routing component, which applies a second routing 
function and forwards the packets to the one or more interface cards for transmission on the 
network. 

An example of this architecture can be seen s e.g., in FIG. 5B of Applicants' disclosure is 
reproduced below, where IFC 16 represents an interface card, 50 represents the routing control 
unit, and MLSC 25 represents a separate service card. 

FIGURE 5B 



IFC 



MLSC 



25 



50 



According to several of the pending claims (and not shown in any of the prior art to date), 
a separate service card (such as MLSC 25) can be selectively added to the router for processing 
of packet communications. MLSC 25 need not receive packets directly from any links, but 
instead may be assigned a network address that resides solely within the router or network device 
for purposes of supporting multi-link protocols (or other services such as prioritization) for 
packets received from other interface cards. The other interface cards, for example, may not 
otherwise support sequencing or fragmentation according to such multi-link protocols. 

In other words, as shown in FIG. 5B (above), interface card 1 6 and MLSC 25 are distinct 
structural cards (sometimes called "line cards") of the router or network device. Interface card 
1 6 receives a set of data blocks from a source within a computer network according to a 
multi-Jink protocol. Routing control unit 50 is coupled to the interface card 16 and multi-link 
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service card 25. Routing control unit 50 performs a routing function and determines that the set 
of data blocks from the interface card 16 are to be forwarded to the multi-link service card 25 for 
sequencing. The arrows extending leftward in FIG. 5B from interface card 16 represent 
communications to and from the network over links to and from interface card 16. Notably, 
MLSC 25 may not even include such links to the outside network. 

The use of a separate multi-link service card to sequence packets that were sent according 
to a multi-link protocol allows a router or other network device to be upgraded to include the 
multi-link service functionality via a distinct card, e.g., that can be inserted or removed from the 
router (see dependent claim 53). 

Contrary to the statements in the Office Action, the Armistead reference fails to disclose 
or suggest the features of Applicants' claims. In fact, the cited passages of the Armistead 
reference actually contradict several of the features of Applicants' claims. 

As a preliminary distinction, Applicants note that the cited passages of Armistead do not 
disclose receiving data packets from a plurality of links in one or more interface cards of a 
network device according to a multi-link protocol and then 3 prior to sequencing the data packets 
in that device, performing a first routing operation to forward the data packets from the one or 
more interface cards to a multi-link service card of the network dcvice ? as required by 
Applicants' claims. Instead, the "routing*' in Armistead carried out by the routing processor is 
the routing of calls over public switching telephone network, see e.g., routing processor 350 and 
PSTN 10 shown in FIGS. 4 and 5 or Armistead. Contrary to the Examiners' argument, the relied 
upon passages of Armistead do not teach routing on a packet-basis (or fragments) to a multi-link 
service card for fragmentation (or sequencing), but rather teaches call routing to a specific 
communication equipment. According to Armistead, routing processor 350 monitors connection 
requests from clients and sets up switch 120 to direct the calls from a client to the same 
communication device. See, e,g., Summary at col. 4, 11. 15-36 and cols. 5-8. The client calls are 
then directed to the particular communication device and processed, such as by handing multi- 
link sessions. Therefore, Armistead fails to suggest a network device that performs a first routing 
function to send packets (or fragments) to a multi-link service card of that device for 
fragmentation (or sequencing). In Armistead, packets are not routed from one or more interface 
cards of a router to a separate service card of the router for any type of processing or sequencing. 
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To the contrary, calls axe merely switched to different communications devices, and those 
communication devices appear to handle PPP and other multilink sessions in a conventional 
manner. 

For example, column 10, lines 38-4 1 (which was relied upon by the Examiner), 
specifically states that "[multi-link protocol] MLP processor 784 can support an MLP session for 
multiple links provided that the links ar e terminated on a DSP connected to the MLP line 
card 790. (emphasis added)" This means that, in Armistead, when a line card is a downstream 
communication device used to support an MLP session, the links associated with that MLP 
session must terminate on that line card. This contradicts the features of Applicants* claims, 
which specifically require that packets received from a plurality of links in one or more interface 
cards are routed to the MLSC, sequenced, and then routed back to the one or more interface cards 
for transmission on the network. In other words, the MLSC that supports a multi-link session 
(according to Applicants' claims) is not same card that receives the packets that are sequenced in 
the MLSC. 

Armistead also provides for MLP sessions from multiple different line cards. However, 
in this case, Armistead requires a specialized multi-rack muKjlink protocol (MMP) processor. At 
column 10 lines 5-7 Armistaed states that: "In FIG. 6, the PPP sessions for each of the links are 
combined in a centralized [multi-rack multilink protocol] MMP processor 690 which combines 
the data from the PPP sessions for output on link 152 to a network." This passage, in direct 
conflict to the features of Applicants' claims, specifically requires that the card supporting the 
multi-link session is a card that outputs communications to the network. Applicants' claims, in 
contrast, require the MLSC that supports a multi-link session to receive fragments routed to the 
MLSC, sequence the fragments, and forward sequenced packets or fragments back to one or 
more different interface cards for transmission on the network. Thus, a first routing function 
causes the fragments to be sent to the MLSC for sequencing and a second routing function causes 
sequenced packets to be transmitted over links of interface cards different from the MLSC. 

In short, the Armistead reference (including the passages specifically relied upon by the 
Examiner) is directly contrary to the features of Applicants' claims. Armistead is generally 
concerned with call routing to a line card in order to initiate a multi-link session, and not packet 
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(or fragment) routing of packets received over multiple links to a specific service card for 
sequencing (or fragmentation). 

Furthermore, Applicants' claims specifically require the use of one or more interface 
cards to send and receive packets, and a separate service card to sequence, fragment or prioritize 
the packets. Following processing by the service card, packets ate forwarded back to the 
interface cards for transmission on the network. Armistead, in opposite, indicates that any line 
card that can support a multi-link session for multiple links provided that the links terminate on a 
DSP connected to that line card. Also, for MMP sessions, in Armistead, the card that supports a 
multi-link session is the same card that outputs communications over links, and clearly is not a 
card that supports sequencing or fragmentation followed by packet or fragment routing back to a 
different card for transmission on the network. These clear differences are irreconcilable. 
Armistead does not teach the features of Applicants* claims. 

The Maurya reference also fails to remedy the clear deficiencies of Armistead. 
Furthermore, the Office Action also misinterpreted Maurya relative to Applicants' claims. Like 
Armistead, the Maurya reference fails to disclose or suggest the use of one or more interface 
cards to send and receive packets, and a separate multi-link service card to process the packets 
according to a multi-link protocol. 

In the Office Action, the Examiner erroneously stated that Armistead "does teach 
performing a second routing operation (sic) in the network device" (citing column 8, lines 1 3- 
29). Nothing in this cited passage of Armistead has any nexus with the passages of Armistead 
cited in the Office Action as teaching the first routing operation. Furthermore, the passages cited 
by the Examiner as teaching the purported "first" routing operation in Armistead actually 
concerns telephone call routing and not packet routing. The passage at column 8, lines 12-29 
teaches nothing that would have suggested any second routing operation consistent with the 
features of Applicants* claims. Nothing in Armistead discloses or suggests both a first routing 
function that causes the packets or fragments to be sent to the MLSC for fragmentation or 
sequencing, and a second routing function causes sequenced packets or fragmented fragments to 
be transmitted over links of interface cards different from the MLSC. 

The Office Action correctly recognized that Armistead fails to teach sending sequenced 
fragments as a sequence data packet to the one or more interface cards of the network device for 



-6- 

PA6E 8/10 * RCVD AT 1/8/2007 5:35:41 PM [Eastern Standard Time] * SVR:USPT0-EFXRF-2/1 7 * DNIS:2738300 * CSID:65173S1102 * DURATION (mm-ss):03-28 



01/08/2087 17:32 6517351102 



SHUMAKER & SIEFFERT 



PAGE 09/10 



Application Number 09/885,223 

Response to Office Action mailed October 6, 2006 

communication to a destination device. For this feature, the Examiner cited several passages of 
Maurya as teaching the communication of multi-link protocol sequenced fragments as sequenced 
data packets to receiving devices over a network. 

Unfortunately, the teaching of Maurya has little in common with the features of 
Applicants' claims. Moreover, whether or not Maurya teaches any communication of multi-link 
protocol sequenced fragments as sequenced data packets to receiving devices is irrelevant 
Applicants* claims require e.g., sending sequenced fragments as a sequenced data packet from an 
MLSC of the router or network device to one ormore other interface cards of the network device, 
Thus, even if Maurya teaches any communication of a sequenced data packet to other devices on 
the network, this reference (like Armistead) lacks any suggestion of the communication of a 
sequenced data packet from an MLSC to one or more other interface cards of the network device 
following the sequencing on the MLSC. 

Claim 50 is somewhat different than the other claims. Claim 50 requires packet reception 
in one or more interface cards, a first routing operation to send the packets to a service card for 
prioritization, and a second routing operation to send the prioritized packets back to the interface 
cards for communication on the network. 

With respect to claim 50, Applicants are confused by the Examiner's rejection. In this 
rejection, the Examiner cited column 9, lines 43-55 of Annistead as teaching a routing operation 
to send the packets to a service card for prioritization. However, the passage of Armistead at 
column 9, lines 43-55 has absolutely nothing to do. with sending packets to a service card for 
prioritization. The Examiner's reliance on column 9, lines 43-55 in the rejection of claim 50 is 
clear factual error. This passage does not teach anything akin to that attributed to this passage by 
the Examiner. None of the applied references discloses or suggests receiving packets in an 
interface card, routing the packets to a different service card (for any reason), and then routing 
the packets from the service card back to the interface card. Clearly, the applied references do 
not suggest the features with the service card performing either multi-link fragmentation or 
sequencing as recited in various claims, or the service card performing packet prioritization as 
required by claim 50. 

As a final note, Applicants do not acquiesce in the Examiner's characterization of the 
various claims as "containing similar limitations" to claim 1 > Some claims, such as claim 32 
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recite features different than claim 1 (e.g., fragmentation rather than sequencing performed in the 
MLCS). These features were not specifically addressed in the Office Action. In any case, the 
comments above demonstrate clear patentable distinctions between the applied references and all 
pending claims. Applicants reserve further comment on the other claims at this time. 

All claims in this application are in condition for allowance. Applicants respectfully 
request reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1 778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 

Date: 



January 8. 2007 

SHUMAKER & SIEFFERT, PA, 
8425 Seasons Parkway, Suite 105 
St. Paul, Minnesota 55125 
Telephone: 651-735.1100 
Facsimile: 651.735.1102 



By: 





Name^/Kelly Patri 
Reg.,No.: 46,326 
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